M-Bus to NB-IoT - Configuration Messages
Guide to the communication protocol of the ACRIOS Systems converters ACR-CV-101N-M-D and ACR-CV-101N-M-EAC.
Introduction
This manual describes a use of the following Lua script which sets up a protocol to communicate with the ACRIOS-CV-101N-M-D and ACR-CV-101N-M-EAC converter and a server configured for this purpose. The system makes use of various payload messages (uplink and downlink) that enable both data gathering and device configuration.
First, we look at general principles used in this communication protocol, then there is an overview of uplink messages (device → server communication), then there is an overview of downlink messages (server → device communication) and finally there is a full example of communication between an ACR-CV unit and the server along with an explanation.
Payload Messages
The communication between the device and the server is achieved with help of payload messages. The payload messages are sent in two directions.
- Uplink Message
- This message type is sent from the converter to the server with the requested information.
- Downlink Message
- This message type is sent from the server to the converter with specific commands.
Uplink Command Bytes
Command Byte | Description |
---|---|
0xF4 | Gather report acked |
0xF5 | M-Bus Scan Done |
0xF0 0xF6 | M-Bus Scan Done NG |
0xF6 | M-Bus IDs Checksum |
0xF9 | Bootloader request |
0xFA | Status report |
0xFE | Configuration Acknowledge |
Downlink Command Bytes
Command Byte | Description |
---|---|
0x01 | Send IDs |
0x02 | Send config |
0x03 | Request config |
0x04 | Request scan |
0x05 | Request IDs |
0x06 | Request status |
0x07 | Request reset |
0x0F | Send initial delay config |
Communication Diagrams
The primary purpose of downlink communication is remote configuration of the target device. Configuration messages are sent in response to specific messages received from the uplink device. In this case all messages qualify for a response, with the exception of bootloader request.
For better understanding, these diagrams graphically represent the communication provided in the section Example.
Initial Start-Up
The process happening after the first initiation is explained in the diagram below.
Configuration
The process of the device configuration is explained in the diagram below.
Gathering
Data is gathered every time the device wakes up. The diagram bellow explains communication between the server and the device.
Uplink Command Bytes
This section provides description for uplink messages that are the individual payloads sent by the converter to the server.
Gather Report (0xF4)
Gather report is sent at the end of data gathering.
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0xF4 | Command byte | [1B] | 1 |
0x02 | Relative counter | [1B] | 2 |
0x01 | IDs received | [1B] | 3 |
If no ID was received, the payload should contain only the first 2 bytes.
Scanning Done (0xF5)
This report is sent after the scanning cycle is completed.
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0xF5 | Command byte | [1B] | 1 |
0x01 | Apply found devices to the filter | [1B] | 2 |
0x60 0x53 0x47 0x01 | ID 01475360 | [4B] | 3-6 |
0x42 0x04 | MAN ID 0442 | [2B] | 7-8 |
0x20 | Version | [1B] | 9 |
0x02 | Medium | [1B] | 10 |
0x31 0x57 0x54 0x01 | ID 01545731 | [4B] | 11-14 |
0x42 0x04 | MAN ID 0442 | [2B] | 15-16 |
0x20 | Version | [1B] | 17 |
0x02 | Medium | [1B] | 18 |
0xXX | N*IDs | [xB] | x |
Choose, whether you want to apply found devices to the filter:
- 00 - Do not apply found devices as new filter.
- 01 - Do apply found devices as new filter replacing the existing ones.
Scanning Done NG (0xF0 0xF6)
This report is sent after the scanning cycle is completed.
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0xF0 0xF6 | Command byte | [1B] | 1 |
0x02 0x00 | Number of unit loads | [1B] | 2 |
0x01 | Apply found devices to the filter | [1B] | 2 |
0x60 0x53 0x47 0x01 | ID 01475360 | [4B] | 3-6 |
0x42 0x04 | MAN ID 0442 | [2B] | 7-8 |
0x20 | Version | [1B] | 9 |
0x02 | Medium | [1B] | 10 |
0x31 0x57 0x54 0x01 | ID 01545731 | [4B] | 11-14 |
0x42 0x04 | MAN ID 0442 | [2B] | 15-16 |
0x20 | Version | [1B] | 17 |
0x02 | Medium | [1B] | 18 |
0xXX | N*IDs | [xB] | x |
Choose which found devices should be applied to the filter:
- 00 - NONE - do not add or apply any IDs.
- 01 - NORMAL - add only scanned IDs.
❗Note that if an ID is stored in the memory, but not received during the scan, it is removed from the list of devices.
- 02 - ADD_ONLY - add only newly found IDs.
M-Bus IDs Checksum (0xF6)
This message confirms the integrity of the transmission.
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0xF6 | Command byte | [1B] | 1 |
0x01 | Filter length [= N] | [1B] | 2 |
0x87 32 00 23 | Checksum | [4B] | 3-6 |
The checksum is calculated with bitwise XOR:
RES1 = 0 ⊕ (ID1) => 0 ⊕ 0x87320020 = 0x87320020
RES2 = (RES1) ⊕ (ID2) => 0x87320020 ⊕ 0x87320021 = 0x01
RES3 = (RES2) ⊕ (ID3) => 0x01 ⊕ 0x87320022 = 0x87320023
…
RESN = (RESN-1) ⊕ (IDN)
The example above shows the checksum for IDs 20003287, 21003287, and 22003287 looks like this: 0x87320023.
Bootloader Request (0xF9)
Note that the following example is split into multiple parts for better understanding, but otherwise it is sent in a form of a single frame.
Below is the first part of the frame, it contains bootloader specific command byte, bootloader version and bootloader request type.
These are the different bootloader request types:
- BL_REQ_ALL - Contains the entire frame, including all three following parts:
- NB-IoT
- Chip IDs
- CRC section
- BL_REQ_NBIOT_IDS - Contains only the NB-IoT related part.
- IMEI, IMSI, ICCID separated with 0x00 (can be be seen in the example below).
- BL_REQ_CHIP_IDS - Contains only chip information.
- BL_REQ_SECTIONS_CRC - Contains only CRC part of the frame.
Example | Description | Size | Byte Number |
---|---|---|---|
0xF9 | Command byte | [1B] | 1 |
0x06 0x06 | Version | [2B] | 2-3 |
0x00 | BL request type | [1B] | 4 |
NB-IoT IDs Section (BL_REQ_NBIOT_IDS)
Payload Description
IMEI
Example | Description | Size | Byte Number |
---|---|---|---|
0x38 0x36 0x38 0x33 0x33 0x33 0x30 0x33 0x35 0x30 0x33 0x37 0x31 0x32 0x32 | IMEI (868333035037122) | xB (ASCII) | 1-15 |
0x00 | Split by zero | [1B] | 16 |
IMSI
Example | Description | Size | Byte Number |
---|---|---|---|
0x39 0x30 0x31 0x34 0x30 0x35 0x37 0x31 0x30 0x30 0x35 0x38 0x39 0x31 0x35 | IMSI (901405710058915) | xB (ASCII) | 1-15 |
0x00 | Split by zero | [1B] | 16 |
ICCID
Example | Description | Size | Byte Number |
---|---|---|---|
0x38 0x39 0x38 0x38 0x32 0x32 0x38 0x30 0x30 0x30 0x30 0x30 0x31 0x30 0x30 0x39 0x35 0x34 0x35 0x39 | ICCID (89882280000010095459) | xB (ASCII) | 1-20 |
0x00 | Split by zero | [1B] | 21 |
Chip IDs Section (BL_REQ_CHIP_IDS)
Payload Description
Chip EUI
Example | Description | Size | Byte Number |
---|---|---|---|
0x5D 0x00 0x31 0x00 0x0D 0x50 0x42 0x59 0x37 0x39 0x38 0x20 | Chip EUI (0x203839375942500D0031005D) | 12B (little endian) | 1-12 |
The following information contains flash size in kB, Chip package and Chip ID & Rev.
Example | Description | Size | Byte Number |
---|---|---|---|
0x00 0x01 0x00 0x00 | Flash size in kB (100 kB) | 4B (little endian) | 1-4 |
0x0A 0x00 0x00 0x00 | Chip package (10) | 4B (little endian) | 5-8 |
0x35 0x64 0x01 0x10 | Chip ID & Rev (REV Z, id 435) | 4B (little endian) | 9-12 |
Chip package types:
These numbers refer to commonly used chip package types.
- 0 - LQFP64
- 10 - UFQFPN48
- 11 - LQFP48
Revision:
These following bytes allow identification of commonly used revisions.
0x10016435 → 0x1001
((0x10016435 & 0xFFFF0000) >> 16)
- 0x1000 - REV A
- 0x1001 - REV Z
- 0x2001 - REV Y
Chip ID:
These following bytes refer to commonly used chip IDs.
0x10016435 & 0xFFF
- 0x435 = STM32L43xxx/STM32L44xxx
- 0x462 = STM32L45xxx/STM32L46xxx
- 0x464 = STM32L41xxx/STM32L42xxx
CRC Section (BL_REQ_SECTIONS_CRC)
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0xF5 0x09 | CRC16 BL | 2B (little endian) | 1-2 |
0x5B 0x1B | CRC16 Config | 2B (little endian) | 3-4 |
0x56 0x38 | CRC16 App | 2B (little endian) | 5-6 |
0x94 0x56 | CRC16 Lua | 2B (little endian) | 7-8 |
0x80 0x9E | CRC16 Fragment | 2B (little endian) | 9-10 |
Status Report (0xFA)
Status report contains signal strength, battery voltage and Lua script version that the device is currently using.
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0xFA | Command byte | [1B] | 1 |
0x0E | Signal [CSQ units] | [1B] | 2 |
0x30 0x0E | Battery voltage [mV] | [2B] | 3-4 |
0x32 2E 30 | Lua script ASCII version | [3B] | 5-7 |
The following example can be interpreted as:
Lua script version → 0x322E30 → 2.0
Signal → 0x0E → 14 CSQ units
Battery voltage → 0x0E30 → 3632 mV
Acknowledge Configuration (0xFE)
This message confirms that the configuration was received.
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0xFE | Command byte | [1B] | 1 |
0x00 | Wake-up period (days) | [1B] | 2 |
0x01 | Wake-up period (hours) | [1B] | 3 |
0x00 | Wake-up period (minutes) | [1B] | 4 |
0x01 | Filter length | [1B] | 5 |
0x01 | Configuration version | [1B] | 6 |
0x60 0x09 | M-Bus baudrate | [2B] | 7-8 |
0x03 | Retry M-Bus reading | [1B] | 9 |
0xB8 0x0B | M-Bus timeout | [2B] | 10-11 |
0x02 | OnStartup Scan mode | [1B] | 12 |
0x00 | VIF/DIF filter index 1 | [1B] | 13 |
0xFF | VIF/DIF filter index 2 | [1B] | 14 |
0xFF | VIF/DIF filter index 3 | [1B] | 15 |
0xFF | VIF/DIF filter index 4 | [1B] | 16 |
0xFF | VIF/DIF filter index 5 | [1B] | 17 |
0xFF | VIF/DIF filter index 6 | [1B] | 18 |
0xFF | VIF/DIF filter index 7 | [1B] | 19 |
0xFF | VIF/DIF filter index 8 | [1B] | 20 |
0xFF | VIF/DIF filter index 9 | [1B] | 21 |
0xFF | VIF/DIF filter index 10 | [1B] | 22 |
0xFF | VIF/DIF filter index 11 | [1B] | 23 |
0xFF | VIF/DIF filter index 12 | [1B] | 24 |
0xFF | VIF/DIF filter index 13 | [1B] | 25 |
0xFF | VIF/DIF filter index 14 | [1B] | 26 |
0xFF | VIF/DIF filter index 15 | [1B] | 27 |
0xFF | VIF/DIF filter index 16 | [1B] | 28 |
0x01 | VIF/DIF filter amount | [1B] | 29 |
0x02 | VIF/DIF filter bytes | [1B] | 30 |
0x04 0x13 | VIF/DIF filter | [2B] | 31-32 |
Index X of VIF/DIF filter either enables or disables a specific VIF/DIF filter for the ID with the given index.
As can be seen from the example above, the last bytes 01 02 04 13
specify the VIF/DIF filter itself:
- 01 - This is the number of VIF/DIF filters for group 0, which is 1 filter.
- 02 - This is the number of following bytes, which is 2 bytes.
- 04 13 - This is the VIF/DIF filter For further details, please see the section Send configuration (0x02).
Downlink Command Bytes
This section provides description for downlink messages that are the individual payloads sent by the server to the converter.
The server side is used for the remote configuration of the converters within installations. By using the server-side for configuration over NB-IoT you can deploy out-of-the-box converters and configure them one by one after the deployment. Feel free to reach out if you are interested in using our server-side API tool.
M-Bus Filter Configuration (0x01)
This command is used to configure M-Bus filter IDs.
Payload Description
Clear Filter
This command is used to clear the existing filter.
Example 1 | Description | Size | Byte Number |
---|---|---|---|
0x01 | Command byte | [1B] | 1 |
0x01 | Clear filter command | [1B] | 2 |
Set M-Bus ID
This command adds new IDs to the existing filter.
Example 2 | Description | Size | Byte Number |
---|---|---|---|
0x01 | Command byte | [1B] | 1 |
0x87 0x32 0x00 0x22 | Set M-Bus ID 22003287 | [4B] | 1-4 |
In case of multiple IDs, the downlink payload for IDs 20003287, 21003287, and 22003287 would look like this: 87 32 00 20 87 32 00 21 87 32 00 22
Uplink response would be in form of this command byte, further described in 0xF6.
Send a Configuration (0x02)
This command sends configuration to the device.
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0x02 | Command byte | [1B] | 1 |
0x00 | Wake-up period (days) | [1B] | 2 |
0x00 | Wake-up period (hours) | [1B] | 3 |
0x1E | Wake-up period (minutes) | [1B] | 4 |
0x60 0x09 | M-Bus baudrate | [2B] | 5-6 |
0x03 | Retry M-Bus reading | [1B] | 7 |
0xB8 0x0B | M-Bus timeout | [2B] | 8-9 |
0x02 | OnStartup Scan mode | [1B] | 10 |
0x00 | VIF/DIF filter index 1 | [1B] | 11 |
0xFF | VIF/DIF filter index 2 | [1B] | 12 |
0xFF | VIF/DIF filter index 3 | [1B] | 13 |
0xFF | VIF/DIF filter index 4 | [1B] | 14 |
0xFF | VIF/DIF filter index 5 | [1B] | 15 |
0xFF | VIF/DIF filter index 6 | [1B] | 16 |
0xFF | VIF/DIF filter index 7 | [1B] | 17 |
0xFF | VIF/DIF filter index 8 | [1B] | 18 |
0xFF | VIF/DIF filter index 9 | [1B] | 19 |
0xFF | VIF/DIF filter index 10 | [1B] | 20 |
0xFF | VIF/DIF filter index 11 | [1B] | 21 |
0xFF | VIF/DIF filter index 12 | [1B] | 22 |
0xFF | VIF/DIF filter index 13 | [1B] | 23 |
0xFF | VIF/DIF filter index 14 | [1B] | 24 |
0xFF | VIF/DIF filter index 15 | [1B] | 25 |
0xFF | VIF/DIF filter index 16 | [1B] | 26 |
0x01 | VIF/DIF filter amount | [1B] | 27 |
0x02 | VIF/DIF filter bytes | [1B] | 28 |
0x04 0x13 | VIF/DIF filter | [2B] | 29-30 |
OnStartup Scan mode has three options:
- 00 - Disable OnStartup Scan.
- 01 - Store only the IDs found during scan.
❗Note that if an ID is stored in the memory, but not received during the scan, it is removed from the list of devices.
- 02 - Add only newly found IDs.
Index X of VIF/DIF filter either enables or disables a specific VIF/DIF filter for the ID with the given index.
As can be seen in example above, the last bytes 01 02 04 13 specify the VIF/DIF filter itself:
- 01 - This is the number of VIF/DIF filters for group 0, which is 1 filter.
- 02 - This is the number of following bytes, which is 2 bytes.
- 04 13 - This is the VIF/DIF filter.
Let's assume, we need to set-up a VIF/DIF filter for two different devices. We'll need to create a VIF/DIF filter with 2 indexes (index 0 and 1).
The VIF/DIF index specification could look like this:
00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF
or this:
01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF
This is based on which M-Bus ID should use VIF/DIF filter with index 0 or 1 (additional details can be found further below).
Here is an example of VIF/DIF filter specification:
02 03 FD DC FF 03 FD C9 FF 02 03 FD DA FF 03 FD C8 FF
02
- This is the number of physical quantities/filters in this first group (index 0).03
- This is the number of following bytes.FD DC FF
- This is the first applied filter in the first group (VIF/DIF - Current).
03
- This is the number of following bytes.FD C9 FF
- This is the second applied filter in first group (VIF/DIF - Voltage).
02
- This is the number of physical quantities/filters in this first group (index 1).03
- This is the number of following bytes.FD DA FF
- This is the first applied filter in second group (VIF/DIF - Current).
03
- This is the number of following bytes.FD C8 FF
- This is the second applied filter in second group (VIF/DIF - Voltage).
Uplink response - command byte 0xFE
Request the Configuration (0x03)
This command requests current device configuration.
Example | Description | Size | Byte Number |
---|---|---|---|
0x03 | Command byte | [1B] | 1 |
Uplink response - command byte 0xFE
Request a M-Bus Scan (0x04)
This command scans for M-Bus devices.
Payload Description
Example | Description | Size | Byte Number |
---|---|---|---|
0x04 | Command byte | [1B] | 1 |
0x01 | Apply newly found devices as new filter | [1B] | 2 |
0xF4 01 | M-Bus response timeout (500 ms) | [2B] | 3-4 |
0x00 | Filter by string (no option) | [1B] | 5 |
Filter by string allows users to scan for ID, Manufacturer ID, Version, Medium and others.
💡 Replace "no option" by criteria you want to filter by.
Apply newly found devices as a new filter:
- 00 - NONE - do not add or apply any IDs.
- 01 - NORMAL - add only scanned IDs.
❗Note that if an ID is stored in the memory, but not received during the scan, it is removed from the list of devices.
- 02 - ADD_ONLY - add only newly found IDs.
Uplink response - command byte 0xF5 or in case of new generation hardware (NG) 0xF0 0xF6
Request a M-Bus Filter Report (0x05)
This command requests current list of M-Bus filters.
Example | Description | Size | Byte Number |
---|---|---|---|
0x05 | Command byte | [1B] | 1 |
0x01 | Send M-Bus filter report request | [1B] | 2 |
Uplink response - command byte 0xF6
Request a Status Report (0x06)
This command requests status report containing signal strength, battery voltage and Lua script version that the device is currently using.
Example | Description | Size | Byte Number |
---|---|---|---|
0x06 | Command byte | [1B] | 1 |
0x01 | Send status report request | [1B] | 2 |
Uplink response - command byte 0xFA
Request a Reset (0x07)
This command executes device reset. It begins with approximately several minutes long bootloader sequence and standard onStartup procedure follows.
Example | Description | Size | Byte Number |
---|---|---|---|
0x07 | Command byte | [1B] | 1 |
0x01 | Send reset request | [1B] | 2 |
Acknowledge (0x08)
This is a server confirmation that the sent data was received.
Example | Description | Size | Byte Number |
---|---|---|---|
0x08 | Command byte | [1B] | 1 |
Initial Delay Configuration (0x0F)
This command configures the initial delay (the delay between enabling M-Bus and first readout).
Example | Description | Size | Byte Number |
---|---|---|---|
0x0F | Command byte | [1B] | 1 |
0xA0 0x0F | Set initial delay to 4 000 ms | [2B] | 2-3 |
Examples of Communication
This section showcases an example of communication between the ACR-CV unit and the server (ACRIOS Backend). The example is split into multiple sections for clarity, but follows the exact order of communication right from the first startup of the ACR-CV unit.
Initial Configuration
First, the bootloader message is sent from the unit:
F9 06 0E 00 38 36 38 33 33 33 30 33 32 31 33 35
33 38 32 00 39 30 31 34 30 35 37 31 30 30 35 38
39 31 36 00 38 39 38 38 32 32 38 30 30 30 30 30
31 30 30 39 35 34 36 37 00 29 00 56 00 03 50 56
37 56 34 34 20 00 01 00 00 0B 00 00 00 35 64 01
10 DE B6 FE CE 91 D2 99 42 C5 1E
To which the server responds with a skip to application command:
4B
The unit switches into the application section of the firmware, scans for any available M-Bus devices and sends a scanning done message :
F5 02 87 32 00 22 77 04 14 07
Then the unit continues by receiving M-Bus data from the meter:
00 68 0F 0F 68 08 00 72 87 32 00 22 77 04 14 07
19 30 00 00 34 16
Which is acknowledged by the server:
08
The unit continues with a gather report procedure:
F4 01 01
To which the server responds with configuration:
02 00 00 1E 60 09 03 B8 0B 02 FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF
The unit responds with configuration acknowledged:
FE 00 00 1E 02 03 60 09 03 B8 0B 02 FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF
The server follows with configuration of M-Bus IDs:
01 87 32 00 22
And lastly, the unit sends an M-Bus IDs checksum to confirm the data integrity:
F6 01 87 32 00 22
By default, the scan is set to be initiated during startup, but it can be triggered remotely as well.
Scanning For Meters
The unit wakes up and sends a gather report:
F4 04 01
The server responds with a scan request:
04 01 F4 01 00
And the unit responds with scanning done which contains found IDs:
F5 02 87 32 00 22 77 04 14 07
To which the server responds with acknowledge:
08
Some devices may not support M-Bus scan. It is possible to set the ID manually for this particular scan.
Configuration
The unit wakes up and sends a gather report:
F4 04 01
The server sends a configuration message first:
02 00 00 1E 60 09 03 B8 0B 02 00 FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF 02 02 0E 84 02 0C
04
The unit responds with configuration acknowledged:
FE 00 00 1E 01 04 60 09 03 B8 0B 02 00 FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF 02 02 0E 84
02 0C 04
Then the server follows with configuration of M-Bus IDs:
01 87 32 00 22 84 01 05 18
To which the unit responds with an M-Bus IDs checksum to confirm the data integrity:
F6 01 87 32 00 22
Data are sent with a signature byte which specifies the index of an M-Bus ID.
Data Report
The unit wakes up and receives the data from the first M-Bus device (M-Bus ID index 0):
00 68 0F 0F 68 08 00 72 87 32 00 22 77 04 14 07
1F 30 00 00 3A 16
This is acknowledged by the server:
08
Then the unit continues with the second M-Bus device (M-Bus ID index 1):
01 68 4B 4B 68 08 00 72 84 01 05 18 25 CD 01 02
00 00 00 00 0C 04 64 07 00 00 8C 10 04 64 07 00
00 8C 20 04 00 00 00 00 1C 04 64 07 00 00 9C 10
04 64 07 00 00 9C 20 04 00 00 00 00 2C 04 01 00
00 00 AC 10 04 01 00 00 00 AC 20 04 00 00 00 00
6F 16
And it is once again acknowledged by the server:
08
Finally, the unit sends a gather report:
F4 06 03
Which is also acknowledged by the server:
08
This section showcases an example of a firmware update procedure, which is the same procedure as Lua script update.
Firmware/Lua Update
The unit wakes up and sends a beacon report:
F0 FF 08 00 B3 AE C1 0F B3 AE C1 0F 36 AE C1 0F
BC AE C1 0F 31 35 2E 31 00 13 13 0E 38 36 38 33
33 33 30 33 35 30 33 37 30 39 38 00 00 02 0D 0B
0D 10 00 00 4E 2F 5B 13 1F 06 00 00 00 00 20 00
00 00 00 00 00 00 00 00 00 00 03 00 00 00 17
To initiate the firmware/Lua update, the server sends a reset request:
07
The unit sends a bootloader request that the server recognized as a successful reset:
F9 06 0E 00 38 36 38 33 33 33 30 33 35 30 33 37
30 39 38 00 39 30 31 34 30 35 37 31 30 30 35 38
39 31 35 00 38 39 38 38 32 32 38 30 30 30 30 30
31 30 30 39 35 34 35 39 00 5A 00 5B 00 0D 50 42
59 37 39 38 20 00 01 00 00 0B 00 00 00 35 64 01
10 9B B7 19 9A D0 6C 6B 1C E3 6D
The server follows with an instruction to erase defined page in the memory:
44 00 00 00 00
The unit responds with acknowledge erase defined page:
F7 44 00 00 00 00
The server sends the first "chunk" of data:
The First "Chunk"
57 00 00 00 00 00 04 5A 56 01 53 90 60 00 1F 00
E8 03 08 07 B5 00 23 01 93 09 B1 FF F7 82 FF 00
20 03 B0 5D F8 04 FB 05 4A 00 23 D1 5C FF 29 0C
04 D1 01 33 08 2B F9 D1 02 48 70 47 00 20 03 04
90 72 FF 1F 60 20 03 1F F8 B5 1B 4B D3 E9 00 45
6B 1C 08 BF B4 F1 FF 3F 09 D0 18 4A D2 E9 00 32
5E 1C 42 F1 00 07 00 2F 06 08 BF 02 2E 02 D3 14
60 23 1F 47 F2 30 53 E0 18 4F F0 00 03 45 EB 03
01 00 23 8B 42 4E F6 60 22 08 BF 82 42 38 BF 00
24 02 F0 1F 99 FA 6F F0 13 03 98 42 B8 BF 18 46
08 4B 37 28 D3 F8 28 31 A8 BF 37 20 90 22 14 38
02 FB 00 30 08 20 44 F8 BD 28 70 FF 1F 30 20 03
00 20 20 03 1F F8 06 00 20 0B 4B 0C 4A 30 B5 1C
46 1D 78 FF 2D 05 D0 00 B1 04 60 09 B1 08 4B 0B
60 30 BD 01 33 14 93 42 F3 D1 08 B1 06 4B 03 60
00 29 F6 D0 05 4B F3 E7 00 BF A0 20 37 00 C0 20
03 00 B0 20 03 00 80 20 03 00 90 20 03 40 CF 1F
00 71 FF 1F 2D E9 F8 43 0F 46 04 46 11 46 38 46
15 46 06 F0 B3 FE 06 46 B0 B1 A1 46 A0 46 2D 1A
1F A8 EB 09 03 9D 42 44 46 01 DA 00 24 0C E0 22
78 3B 78 9A 42 08 F1 01 08 F2 D1 32 46 39 46 20
46 1A 21 F0 2F FA 00 28 EB D1 20 46 BD E8 F8 83
00 00 2D E9 F0 41 04 46 FE F7 99 FE 20 20 05 00
96 60 05 1F 93 FE 11 4E 09 25 04 F5 00 67 23 46
BB 42 03 D1 0E 4A 23 46 03 21 11 E0 53 F8 04 2B
01 32 F5 D0 04 0B 48 23 46 32 20 11 03 FF F7 5E
F8 40 35 06 7B FE 01 3D E9 D1 07 20 25 12 01 21
BD E8 F0 41 03 48 FF F7 51 B8 00 BF 6C 20 03 08
5E 20 03 00 58 20 03 00 19 20 03 40 6B 0F 8C B0
03 A9 07 F0 74 FC 08 9B 03 B3 24 4D 2B 78 20 05
1F 4B 18 68 A0 F5 7F 50 3F 38 FF F7 B8 FF 2B 78
08 9E C3 B1 1F 4B 1C 68 A4 F5 7F 54 3F 3C 1D 4F
DF 1C F8 70 80 2B 78 83 B3 D8 F8 00 30 A3 F5 7F
53 3F 3B BD F8 24 20 13 44 9C 42 06 D3 0C B0 20
6F 11 81 14 48 E1 E7 13 4C E9 E7 08 22 31 46 68
46 20 F0 A1 20 45 01 B3 B1 20 2F 1D 10 A1 F5 7F
51 3F 39 61 1A 08 22 68 46 FF F7 F3 FD FB F7 9F
FD 21 46 DD E9 00 23 00 20 FB 20 0F 1A 08 36 FB
F7 A8 FD 08 34 CE E7 39 46 EB E7 3B 46 D1 E7 10
09 00 20 7C 04 00 20 00 22 67 1F 30 B5 87 B0 0D
46 00 21 01 91 01 A9 FF F7 EA FD 01 9B 02 3B 01
93 05 93 19 4B D3 F8 24 31 05 F1 0C 80 04 01 33
04 93 C4 F3 0A 03 13 B9 20 20 5F 05 59 FF 4F F0
FF 32 20 03 09 33 CD E9 02 23 F8 35 FB F7 68 60
6D 00 02 20 6D 04 08 34 FB F7 BB 20 7F 15 71 FD
A5 42 F2 D1 08 22 04 A9 0D EB 02 00 20 F0 4B FF
FB F7 55 FD 40 23 01 29 46 40 93 00 A9 20 23 07
5F FD 07 B0 30 BD 00 BF 42 37 0B 2D E9 F7 4F 40
4D 41 4C DF F8 04 A1 20 03 1B B1 64 1B 04 EB D4
74 4F EA 64 09 64 10 48 BF 04 F2 FF 74 2E 46 E4
12 00 27 D0 46 9A 21 1F 04 00 2B 44 D0 DB 20 07
81 27 1F 9B 1B 03 EB D3 73 05 EB 63 03 9B 1B 48
BF 03 F2 FF 73 DB 12 9F 42 1E DB DF F8 BC A0 E4
02 00 27 00 98 20 29 04 00 2B 4E D0 DA 20 07 E0
0F 31 0C 23 F4 FF 63 23 F0 07 03 9F 42 19 DB 03
41 6D 00 8F 40 35 01 7B B1 20 65 00 00 81 B5 1F
80 1B 00 EB D0 70 40 10 05 EB C7 23 18 44 FF F7
D6 FE 01 37 B8 E7 48 46 F6 E7 23 46 C7 E7 07 EB
04 05 0B 08 22 59 61 97 05 D5 FE FB F7 DF FC 40
3F 01 93 B1 E0 07 73 01 59 10 41 95 01 59 44 41
03 0C 27 FD 08 37 FB F7 DC FC AE E7 49 46 F3 20
45 00 C0 23 0F 03 00 68 03 08 41 93 C1 9F 22 4B
02 4F 6B 4D 20 C9 1F 91 DF F8 C8 B1 87 B0 00 23
AD F8 04 30 AD F8 06 30 02 93 AB 68 4B 45 07 46
0E 46 90 46 CA 46 10
The unit responds with acknowledged command and a checksum of received data to confirm the data integrity:
F7 57 00 00 00 00 00 04 2B
And the communication continues until all the data are transferred into the unit.
...
After enough data are stored in the unit, the server sends command to decompress the data and flash them into memory:
58 00 60 00 00 7D
To which the unit responds with an acknowledged command and a checksum to confirm the data integrity:
F7 58 00 80 01 00 94
The process repeats until the last page is written into the unit. Here is the checksum of lastly flashed section:
F7 58 00 00 00 00 5A
Then the server responds with a clear bootloader timeout command:
4C
The unit sends acknowledge:
F7 4C
The server requests CRC-16 checksum of the pages:
43
The unit responds with the CRC-16 checksum of the pages:
F7 43 C9 63 A7 36 2B 74 28 16 F9 28 3E 8D 7E A6
F0 65 01 0D A1 1B 65 05 A4 29 48 95 3E 27 FE CE
19 9A 93 B0 EE 80 51 78 D1 0D D5 4E BF 1D 6A B4
5B 87 51 0D CA E8 A5 EA 9B AE 05 22 AE CD E9 58
90 20 33 B5 8E 8F 58 C9 F7 13 3B B7 5D 8D A2 A1
C9 E1 D8 A9 7C ED 33 0F FC E2 61 20 10 C9 8D 8C
8A 19 68 3D 89 F6 74 15 8D 71 98 94 6C AF 42 24
6B BE 30 0C 30 31 4D 30 D2 62 60 03 8A 7F 4D BA
C3 D8 64 2C 40 6C 28 C2 94 C8 28 C2 05 E4 2A 42
E7 59 19 98 88 32 79 6F 5D 1E 1A 04 EE DD AC AB
7D C8 F3 D8 8A 79 47 FB 03 A5 A8 C3 9F 9F B2 57
61 8B DF AC 9E 4B B7 98 ED 01 B0 1E 2E 25 AF F6
31 25 CA 0A 2D 77 F6 F8 DF 4D F4 A6 D1 84 60 A5
C9 F4 C2 0F D6 E1 EF 7F F6 CC 99 74 F7 CC A0 0E
D3 06 25 96 19 79 05 FD 37 ED 7C 7A D2 F6 D3 74
FE CE FE CE FE CE FE CE FE CE FE CE FE CE FE CE
FE CE
Finally, the server sends a skip to application command:
4B
VIF/DIF Filter Use
The full M-Bus frame of the Itron M-Bus Cyble v2.0 looks like this:
68 56 56 68 08 00 72 87 32 00 22 77 04 14 07 0B
30 00 00 0C 78 87 32 00 22 0D 7C 08 44 49 20 2E
74 73 75 63 0A 20 20 20 20 20 20 20 20 20 20 04
6D 1D 14 09 31 02 7C 09 65 6D 69 74 20 2E 74 61
62 E0 12 04 13 00 00 00 00 04 93 7F 00 00 00 00
44 13 00 00 00 00 0F 10 00 1F 45 16
If we parse the payload above, we receive the following values:
ID: 22003287
MAN:ACW
MED:WATER
GEN:20
ACC:11
STA:48the
SIG:0
DIF:0Ch VIF:78h Data:87320022h - FAB number 22003287
DIF:0Dh VIF:7Ch Data:20202020202020202020h - DI .tsuc ---
DIF:04h VIF:6Dh Data:1D140931h - 09.01.2024 20:29
DIF:02h VIF:7Ch Data:E012h - emit .tab 4832
DIF:04h VIF:13h Data:00000000h - Volume 0 m³
DIF:04h VIF:93h VIFE:7Fh Data:00000000h - Volume 0 m³
DIF:44h VIF:13h Data:00000000h - Volume 0 m³ Storage:1
MDH: 0Fh
MfgData: 10001F
Let's assume we only require the volume in cubic meters. In order to extract the necessary value, the VIF/DIF filter can be configured as follows: 04 13
.
To do this, the configuration is sent.
The following command also sets the wake-up period to 30 minutes:
02 00 00 1E 60 09 03 B8 0B 02 00 FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF
01 02 04 13
Payload Description
General Configuration
Example | Description | Size | Byte Number |
---|---|---|---|
0x02 | Command byte | [1B] | 1 |
0x00 | Wake-up period (days) | [1B] | 2 |
0x00 | Wake-up period (hours) | [1B] | 3 |
0x1E | Wake-up period (minutes) | [1B] | 4 |
0x60 0x09 | M-Bus baudrate | [2B] | 5-6 |
0x03 | Retry M-Bus reading | [1B] | 7 |
0xB8 0x0B | M-Bus timeout | [2B] | 8-9 |
0x02 | OnStartup Scan mode | [1B] | 10 |
VIF/DIF Filter
Example | Description | Size | Byte Number |
---|---|---|---|
0x00 | VIF/DIF filter index 1 [set to group 0] | [1B] | 11 |
0xFF | VIF/DIF filter index 2 | [1B] | 12 |
0xFF | VIF/DIF filter index 3 | [1B] | 13 |
0xFF | VIF/DIF filter index 4 | [1B] | 14 |
0xFF | VIF/DIF filter index 5 | [1B] | 15 |
0xFF | VIF/DIF filter index 6 | [1B] | 16 |
0xFF | VIF/DIF filter index 7 | [1B] | 17 |
0xFF | VIF/DIF filter index 8 | [1B] | 18 |
0xFF | VIF/DIF filter index 9 | [1B] | 19 |
0xFF | VIF/DIF filter index 10 | [1B] | 20 |
0xFF | VIF/DIF filter index 11 | [1B] | 21 |
0xFF | VIF/DIF filter index 12 | [1B] | 22 |
0xFF | VIF/DIF filter index 13 | [1B] | 23 |
0xFF | VIF/DIF filter index 14 | [1B] | 24 |
0xFF | VIF/DIF filter index 15 | [1B] | 25 |
0xFF | VIF/DIF filter index 16 | [1B] | 26 |
0x01 | VIF/DIF filter amount [group 0] | [1B] | 27 |
0x02 | VIF/DIF filter bytes | [1B] | 28 |
0x04 0x13 | VIF/DIF filter [group 0] | [2B] | 29-30 |
If more than one group of filters is needed, use:
Example | Description | Size | Byte Number |
---|---|---|---|
0x02 | VIF/DIF filter amount [group 1] | [1B] | 31 |
0x02 | VIF/DIF filter bytes | [1B] | 32 |
0x0E 0x84 | VIF/DIF filter [group 1] | [2B] | 33-34 |
0x02 | VIF/DIF filter bytes | [1B] | 35 |
0x0E 0x84 | VIF/DIF filter [group 1] | [2B] | 36-37 |
After receiving the confirmation-0xFE from the network server, the next M-Bus Frame is reduced:
68 15 15 68 08 00 72 87 32 00 22 77 04 14 07 6B 30 00 00 04 13 00 00 00 00 9D 16
When parsed:
HEADER
ID: 22003287 MAN:ACW MED:WATER GEN:20 ACC:107 STA:48 SIG:0
RECORDS
DIF:04h (Int32) VIF:13h Data:00000000h Volume 0 m³
MDH: 00h
M-Bus Payload Parsing
The payload itself is in a form of typical M-Bus frame, including the header and any M-Bus parser can be used. We recommend using one of the parsers below. Please always check for a possible licensing model.
💡 Alexander Miller M-Bus parser
💡 libmbus - M-bus Library from Raditex Control
Here is an example using docker to run libmbus service.